1. Field of the Invention
Embodiments of the present invention relate, in general, to validation of software and particularly to the validation of code that initializes a computer system.
2. Relevant Background
Computer platforms are widely available and are central to the growing reliance on electronic business and commerce in the present economy. This growth is coupled with the need to protect information, particularly information with regard to the type of computers utilized on a day-to-day basis. Although businesses now use secure operating systems on servers and have physically protected individual server platforms, a corresponding improvement in client platforms has failed to occur because of the ad hoc way in which client platforms develop, the sheer number of such platforms, and the cost.
As conventional businesses increasingly depend on personal computers (“PCs”) and the Internet for their success, the trustworthiness of PCs and other platforms is an increasingly vital issue. The development of e-services and the convenience of using the same computer platform for both personal and business activities mean that users increasingly need to store and use sensitive data on these platforms. However, the ability to protect a PC or other computing platform through software alone has inherent weaknesses. The degree of confidence in software-only security solutions depends on their correct installation and operation. Even the most robust and tightly controlled software cannot vouch for its own integrity.
For example, if malicious software has bypassed the security mechanisms of an operating system (“OS”) and managed to corrupt the basic behavior of the OS, by definition it is impossible to expect that the OS will necessarily be aware of this security breach. To address this need the concept of a Trusted Platform Module was created.
A Trusted Platform Module (“TPM”) is generally known to one skilled in the art as a secure storage chip for unique Public Key Infrastructure (“PKI”) key pairs and credentials. In other words, it is the “safety box” where keys of encrypted data can be kept. The TPM also contains protected registers that can store software measurements in the form of cryptographic hashes of executable code or configuration data. The stored values can be extended with additional measurements, but existing measurements cannot be overwritten except by resetting the computer system. Thus the TPM presents a simple interface for binding data to the current platform configuration.
Upon generation of a key or certificate for encrypted data by system software, those keys and certificates are sealed in the TPM. These stored information bits authenticate and provide information on the integrity of the platform when needed and inform the user of the status of particular pieces of hardware or software. The status is provided based on the uniqueness of the platform, which, in turn, is based on the unique keys stored in the TPM.
For example, when the TPM protected object is created, the creator indicates the software state that must exist if the secret is to be revealed. When a TPM unwraps the TPM protected object (within the TPM and hidden from view), the TPM checks that the current software state matches the indicated software state. If they match, the TPM permits access to the secret. If they do not match, the TPM denies access to the secret.
Sealing encrypts data in such a way that it may be decrypted only if the TPM releases the associated decryption key, which it only does when the exact same software is present as was specified when the data was encrypted.
However, lacking in the TPM architecture is a validation of the underlying boot sequence of a computer. Current implementation of TPM architecture and the like is limited to controlling access to data after the operating system has booted. The boot sequence itself remains vulnerable to attack, and should it be attacked by malicious code the trustworthiness of the entire platform is jeopardized. Furthermore, there is no protection against the modification of code, be it either by accident or via a malicious act, after an initial validation but prior to the code's execution.